Modern Universal Mobile Telecommunications System (UMTS) chip sets often support two or more different Radio Access Technologies (RATs) such as GPRS, Enhanced Data rates for GSM Evolution (EDGE), Wide Band Code Division Multiple Access (WCDMA) and evolved High Speed Packet Access (eHSPA). Regardless of the RAT currently active, a multi-RAT UMTS User Equipment (UE) is always connected to the same packet-switched domain, the GPRS packet domain, for packet switched services. The UE may thus always use the same principles for Internet Protocol (IP) bearer and connection management and allocation.
IP bearer and connection management and allocation in the GPRS packet domain is based on Packet Data Protocol (PDP) contexts and comprises functions for activating, deactivating and modifying bearers and connections as generally described in the Technical Specification (TS) 24.008 “Mobile Radio Interface Layer 3 Specification; Core Network Protocols; Stage 3” of the 3rd Generation Partnership Project (3GPP). A PDP context can be regarded as a data record of parameters that characterize a specific bearer and connection to the target Packet Data Network (PDN).
Multiple applications running on one UE may require multiple connections to one or more PDNs, so that multiple PDP contexts may have to be defined. These multiple PDP contexts can be grouped into so-called primary PDP contexts (also referred to as non-secondary PDP contexts hereinafter) on the one hand and secondary PDP contexts on the other.
Multiple primary PDP contexts provide connections to different PDNs and are each associated with a unique IP address. Each secondary PDP context is created based on an existing primary PDP context and provides a connection to the same PDN as this primary PDP context. However, the secondary PDP context is typically associated with a different Quality of Service (QoS) guarantee than the associated primary PDP context. Each primary and secondary PDP context has its own Radio Access Bearer (RAB) and is identified by a unique Network Layer Service Access Point Identifier (NSAPI) used both in the GPRS packet domain and locally by the UE.
Since the IP address is the same for the primary PDP context and its associated secondary PDP contexts, a Gateway GPRS Support Node (GGSN) in the GPRS packet domain requires a filter to route downlink user plane data into the correct RAB for the primary and secondary PDP contexts. This filter is set using a so-called Traffic Flow Template (TFT) communicated by the UE in the Activate Secondary PDP Context Request message to the GGSN.
In existing solutions the IP bearer and connection management and allocation scheme as defined in the 3GPP specifications for the link between the GPRS packet domain and the layer 3 functionalities of the UE is also used towards applications that utilize these layer 3 functionalities for data transfer. Such applications can either be installed internally in the UE or externally on a terminal device to which the UE provides modem services.
The IP bearer and connection management and allocation functionality can be provided towards the applications (and the terminal device) using an Application Programming Interface (API). For internal applications, the API may be realized in the form of a so-called Open Platform API (OPA) as described in A. Ghosh et al., “Open application environments in mobile devices: Focus on PIE and Ericsson Mobile Platforms”, Ericsson Review, Volume 82, 2005. Alternatively (e.g., for external applications), the IP bearer and connection management and allocation functionality may be provided through an AT command API in accordance with 3GPP TS 27.007 “AT command set for User Equipments (UE)”.
As illustrated in FIG. 1, AT commands are used for controlling Mobile Termination (MT) functions as well as services in the GPRS packet domain from a Terminal Equipment (TE) through a Terminal Adapter (TA). TA, MT and TE may be implemented in the form of separate or integrated entities as needed. 3GPP TS 27.007 defines a plurality of AT commands for controlling MT functions and GPRS packet domain services based on PDP contexts. Each AT command includes a Context Identification (CID) parameter as reference to the specific PDP context (and the associated RAB) to which the AT command applies.
With Release 8 of the 3GPP specifications, the Long Term Evolution (LTE) RAT and the Evolved Packet System (EPS) are introduced. The EPS is the packet domain that will be used by a UE in the LTE mode instead of the conventional GPRS packet domain.
The GPRS packet domain and the EPS packet domain differ in many aspects. For example, instead of relying on PDP contexts, the EPS is based on a Non-Access Stratum (NAS) protocol that defines default bearers, dedicated bearers and Service Data Flows (SDFs, also called ESP bearer resources) as described in 3GPP TS 23.401
“GPRS enhancements for E-UTRAN access” and 3GPP TS 24.301 “Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS); Core Network Protocols; Stage 3”. Moreover, EPS bearer setup procedures are always triggered by the network side, whereas in the GPRS packet domain the UE initiates PDP context setup.
In the EPS, a bearer is the basic level of QoS control granularity (which means that all data traffic on the same EPS bearer is granted the same QoS guarantee and that different QoS guarantees may be provided for different bearers). An EPS default bearer is set up according to a defaults QoS profile in the process of initial UE network attachment. As a result, each UE has at least one active (default) bearer to speed up service initiation. Additional EPS bearers connected to the same PDN like the default bearer are called dedicated bearers and will typically have a different QoS profile than the associated default bearer.
The EPS SDF feature has similarities with the GPRS TFT feature in that each SDF can be regarded as being associated with a packet filter or packet filter aggregate (e.g., multiple uplink and downlink packet filters). Additionally, each SDF is associated with a specific QoS profile. An SDF is based on an EPS bearer, and several SDFs with the same QoS profile may build an aggregated SDF mapped to a single EPS bearer.
Contrary to GPRS, where the decision how to map TFTs and PDP contexts is performed in the UE, in the EPS the network decides how the mapping will be performed. As a result, an LTE Resource Allocation Request message for an SDF issued by an UE via NAS signalling can either return a new EPS dedicated bearer with the requested SDF or an already existing EPS (dedicated or default) bearer with an additional SDF. In the GPRS packet domain, the corresponding Secondary PDP Context Activate Request message would always return a new (secondary) PDP context with an associated RAB.
There generally exist several possibilities how to create an interface towards applications for IP bearer and connection management and allocation in the EPS. A first solution could re-use the concept as specified in 3GPP TS 24.301 for the interface between the UE layer 3 functionalities and the EPS also as a basis for the interface towards the applications residing on the UE or on a terminal device to which the UE is connected. Such an interface towards the applications would comprise EPS specific messages like Bearer Resource Allocation/Release Request messages, Activate Default/Dedicated EPS Bearer Context Request messages, and so on.
While this solution would work for a single-RAT UE providing only LTE support, it would be disadvantageous for an LTE-enabled multi-RAT UE that connects to the EPS packet domain for LTE bearers and to the GPRS packet domain for legacy UMTS bearers. Specifically, such a solution would require that the interface towards the applications for IP bearer and connection management and allocation would be different dependent on the active RAT. It would, however, in many cases be desirable that the applications can request packet-based services independently of the active RAT (i.e., that the applications can remain agnostic of the RAT currently in use).
A second interference solution could be the programming of a dedicated interface capable of interpreting PDP contexts as EPS bearers and vice versa. According to the second solution, a primary PDP context could be interpreted to correspond to an EPS default bearer, and a secondary PDP context could be interpreted to correspond to an EPS dedicated bearer. As a result, the AT command interface for LTE bearer control could re-use an existing AT command interface for GPRS packet domain control to a large extent.
The main drawbacks of the second solution are the different bearer activation approaches discussed above. That is, for GPRS packet domain bearers the UE decides whether a new PDP context shall be activated, whereas for the EPS packet domain it is the network that decides about the activation of a new EPS bearer. As a result, certain AT commands such as the PDP context/EPS bearer activation request (+CGACT) would have to be interpreted differently dependent on the active RAT. Consequently, additional logic will need to be implemented on the application side to handle the differences between the LTE RAT on the one hand and the legacy UMTS RATs on the other. This also implies that applications programmed for the GPRS packet domain might need to be updated to support the EPS packet domain.